REMARKS 

Reconsideration and allowance of the above-referenced application are respectfully 
requested. Claims 23, 28, and 34 are canceled, claims 2 and 20 are amended, and claims 1-22, 
24-27, 29-33, and 35-42 are pending in the application. 

The Examiner's attention is directed to the fact that claims 1-22, 24-27, 29-33, and 35-42 
are pending in the application, as the Office Action erroneously specifies that claims 1-42 are 
pending. 

The indication of allowable subject matter in pending claims 2-11, 14-18, 20-22, 24-27, 
29, 31-33, and 35-39 is acknowledged with appreciation. In view of the following comments, 
including the arguments with respect to independent claims 1, 12, 19, and 30, it is believed these 
claims are still in allowable form. 

Claims 2 and 20 have been amended to ensure the claims are accurately interpreted that 
either A or B should be used, as opposed to the improper interpretation that both A and B must 
be used, as suggested by recent Federal Circuit decisions. 1 Use of the term "or" has been deemed 
acceptable under 35 USC §112, second paragraph. See MPEP 2173.05(h)H. at 2100-222 (Rev. 
3, Aug. 2005) (citing In re Gaubert, 524 R2d 1222, 187 USPQ 664 (CCPA 1975)). Hence, it is 
believed the amendments are proper and do not raise any new issues. 

Claims 1, 12-13, 19, 30 and 40-42 stand rejected under 35 USC §103 in view of U.S. 
Patent Publication No. 2002/0055980 to Goddard and U.S. Patent No. 5,933, 602 to Grover. 
These rejections are respectfully traversed. 

Each of the independent claims 1, 12, 19 and 30 specify emulation in ^protocol 
emulator, where IP frames are promiscuously detected on a network interface. An executable 
emulation application within the protocol emulator generates , for each corresponding detected 
IP frame, a response IP frame. Each response IP frame is output by a raw socket onto the 
network interface. 



l See Super guide Corp v. DirecTV Enterprises, Inc., 358 F.3d 870, 886-87 (Fed. Cir. 

2004). 
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As described in the specification (e.g., page 2, lines 17-23, page 2, line 28 to page 3, line 
3), the claimed protocol emulator is able to emulate an unlimited number of IP addresses based 
on scalable operations, such as promiscuous detection of IP frames on the network interface that 
eliminates the necessity for conventional IP filtering of received IP frames that normally is 
performed by a UNIX kernel. Moreover, the generation of a response IP frame for each 
corresponding detected IP frame results in the executable emulation application being able to 
emulate an unlimited number of IP devices, since a UNIX descriptor is no longer needed for each 
and every IP address emulated by the protocol emulator; rather, the executable emulation 
application generates a response IP frame for each detected IP frame, regardless of IP address. 
Finally, each response IP frame is output by the raw socket onto the network interface, enabling 
kernel resources to be bypassed, further reducing the reliance on operating system resources such 
as the UNIX kernel. 

These and other features are neither disclosed nor suggested in the applied prior art. 
Goddard 

Goddard provides no disclosure or suggestion of any protocol emulation, as claimed. 
Rather, Goddard describes a dispatcher (e.g., 102 of Fig. 1,212 of Fig. 2, para. 28-31) that 
receives client requests from client devices, and selectively forwards the requests to a back-end 
server (e.g., 104 of Fig. 1 , 202/204 of Fig. 2) that executes the client requests. In fact, Goddard 
emphasizes that "the performance of a server may be enhanced by limiting the amount of data 
processed by that server at any given time " (para. 33). For this reason alone the §103 rejection 
should be withdrawn. 

Further, even though Goddard describes in para. 55-56 a "promiscuous mode", each 

packet received by the dispatcher still undergoes filtering bv the dispatcher : 

[0055] When a packet arrives at the datalink layer of the dispatcher 210, the packet is 
preferably applied to each filter defined by the dispatcher, as shown in FIG. 5. The 
packet capture device then captures all the packets in which it is interested. For example, 
the packet capture device can operate in a promiscuous mode , during which all packets 
arriving at the datalink layer are copied to a packet capture buffer and then filtered. 



Amendment filed March 6, 2007 
Appln. No. 09/725,930 
Page 1 1 



through software, according to. e.g.. their source IP or MAC address, protocol type, 
etc. Matching packets can then be forwarded to the application making the packet 
capture call, whereas non-matching packets can be discarded . Alternatively, packets 
arriving at the datalink layer can be filtered through hardware (e.g., via a network 
interface card) in addition to or instead of software filtering. ... 

Hence, Goddard explicitly requires packet filtering to performed before the packet is sent 
to the application layer, even if packets are received in promiscuous mode, and neither discloses 
nor suggests generating,/or each corresponding (promiscuously) detected IP frame, a response 
IP frame by an executable emulation application, as claimed. Moreover, Goddard specifically 
avoids generating a response IP frame for each promiscuously detected IP frame by (1 ) filtering 
the promiscuously detected packets based on MAC addresses or IP addresses, and (2) selectively 
dropping packets that do not meet the prescribed criteria (e.g., as specified in para. 55), or 
denying client service requests due to overload conditions (e.g., para. 37, lines 3-9; para. 43, 45). 

As admitted in the rejection, Goddard fails to disclose or suggest generating a response IP 
frame for each corresponding (promiscuously) detected frame. Moreover, Goddard is incapable 
of generating a response IP frame for each corresponding (promiscuously) detected IP frame, 
because Goddard requires filtering of incoming packets by the dispatcher in order to prevent 
overloading of the back-end server. 

Grover 

Grover does not teach or suggest "generating a response frame for each detected IP 
frame", as asserted; as described below, Grover teaches no more than detecting whether a 
response has been received for a detected command frame, and further teaches away from the 
claimed "generating a response frame for each detected IP frame" by droppine or filtering out 
detected packets that do not satisfy prescribed selection criteria, in order to isolate command and 
response packets. 

Grover specifically teaches that M [t]he invention isolates command and response packets 
from the many other disparate types of packets communicated on a communications channel" 
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(column 1, lines 15-18), and that "[t]he method and apparatus according to this invention can 
quickly isolate from what may be a large number of packets communicated over network 20 in a 
short period of time only those packets which are command and response packets, and can pair a 
command packet with its corresponding response packet" (column 6, line 64 to column 7, line 2). 

Grover specifically teaches away from the claimed feature of "generating, for each 
corresponding detected IP frame, a response IP frame" by specifically teaching selecting the 
command and response packets from other detected packets based on dropping nonrelevant 
packets from the stream of packets to recover only the command and response packets. Grover 
teaches in Figure 1 that a workstation 30 includes a test tool 34 that initiates a packet prescan 31 : 
the packet prescan 31 "can scan packets received by network card 28 and quickly eliminate 
further processing of any packets which are not command or response packets, or which are 
packets communicated between nodes other than nodes 24 and 25" (column 6, lines 7-11). 

Further, any promiscuous mode by the network card 28 is solely to permit the packet 
prescan 3 1 to "analyze each packet to determine if it is a command and a response packet and 
should be farther [sic] analyzed, or if it should be discarded" (see column 6, lines 20-27). In fact, 
Figure 2 "illustrates a series of windows which test tool 34 can utilize to allow for additional user 
selection criteria in determining which command and response packets are to be captured, to 
further reduce the number of irrelevant packets captured by test tool 34" (column 7, lines 20-24); 
Figure 4 illustrates that M [i]f the packet is not a command or response packet, packet prescan 31 
stops it [at] block 60 and awaits the next packet from network card 28" (column 8, lines 52-54), 
"[i]f the source address of the packet does not match either of the addresses of the preselected 
nodes, then packet prescan 31 stops processing of the packet at block 68" (column 8, lines 59- 
61), and "[i]f [the destination] address does not match, then the packet is not relevant and packet 
prescan 31 stops at block 63" (column 8, lines 65-67). 

Further, the cited portion in columns 13-14 describing Figure 1 1 relate to performing 

filtering on a previously captured collection of packets: 

test tool 34 can process a previously captured collection of packets and display to a user 
only command and response packets of interest. This process is generally referred to in 
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the art as filtering. Filtering allows a user to indicate to test tool 34 that all packets which 
contain one or more predetermined characteristics should be displayed, and that all other 
packets should be ignored. 

(Column 11, lines 25-32). 

Further, Grover specifies that M [w]hen carrying out the filtering process according to one 
preferred embodiment of this invention, test tool 34 presumes that the collection of command 
and response packets is in a chronological command in response packet order. ... one process for 
reordering a collection of command in response packets which are not necessarily in 
chronological order is illustrated in FIG. 11." (Column 13, lines 29-32 and 38-43). 

Hence, Grover does not disclose or suggest generating, for each corresponding 
(promiscuously) detected IP frame, a response IP frame, as claimed, but consistently teaches 
away from this claimed feature by explicitly teaching dropping nonrelevant packets, or filtering a 
previously captured collection of packets by displaying only command and response packets of 
interest, and ignoring all other packets. 2 For this reason alone the §103 rejection should be 
withdrawn. 

Further, Grover does not disclose or suggest generating a response IP frame, for each 
corresponding detected IP frame, by an executable emulation application in the protocol 
emulator; rather, Grover consistently teaches capturing the response packet from the network 20 
by the packet prescan 31 , and reviewing the received response packet by the test tool 34. For this 
reason alone the §103 rejection should be withdrawn. 



2t 'A prior art reference must be considered in its entirety, i.e., as a whole , including 
portions that would lead away from the claimed invention. MPEP §2141.02, page 2100-124 
(Rev. 5, Aug. 2006) (citing W.L. Gore & Assoc. v. Garlock, Inc., 220 USPQ 303 (Fed. Cir. 
1983), cert, denied, 469 U.S. 851 (1984))(emphasis in original). 
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The Hypothetical Combination 

The rejection fails to establish a prima facie case of obviousness, because the rejection 
fails to demonstrate that one having ordinary skill in the art would have been motivated to 
modify the references in order to obtain the claimed features in the manner claimed. An 
obviousness rejection requires a specific showing as to why one of ordinary skill in the art would 
have selected the components for combination in the manner claimed . 3 "The examiner's 
conclusory statements ... do not adequately address the issue of motivation to combine. This 
factual question of motivation is material to patentability, and [cannot] be resolved on subjective 
belief and unknown authority. It is improper, in determining whether a person of ordinary skill 
would have been led to this combination of references, simply to '[use] that which the inventor 
taught against its teacher.'" In re Lee, 61 USPQ2d at. 1434 {quoting W.L Gore v. Garlock, Inc.,, 
202 USPQ 303, 312-13 (Fed. Cir. 1983)). 

In fact, the alleged motivation specified in the rejection demonstrates the exact opposite 

of what is claimed, and actually teaches away from the claimed feature of generating a response 

frame for each corresponding (promiscuously) detected IP frame. 

Given the teaching of Grover, a person of ordinary skill in the art would have readily 
recognized the desirability and the advantage of modifying Goddard by employing the 
system [of] Grover which can extract only command and corresponding response 
packets which would greatly ease the development of software and hardware which 
utilizes a command and response protocol. 

Hence, even the alleged motivation demonstrates that one having ordinary skill in the art 
would not generate a response IP frame for each corresponding (promiscuously) detected IP 



3 Cf. In re Lee, 61 USPQ2d 1430, 1433-34 (Fed. Cir. 2002) {quoting In re Kotzab, 217 
F.3d 1365, 1371, 55 USPQ2d 1313, 1317 ("particular findings must be made as to the reason the 
skilled artisan, with no knowledge of the claimed invention, would have selected these 
components for combination in the manner claimed"); In re Roujfet, 149 F.3d 1350, 1357, 47 
USPQ2d 1453, 1458 (Fed. Cir. 1998) ("the examiner must show reasons that the skilled artisan, 
confronted with the same problems as the inventor and with no knowledge of the claimed 
invention, would select the elements from the cited prior art references for combination in the 
manner claimed ." (emphasis added)). 
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frame, as claimed; rather, the rejection concedes that one of ordinary skill in the art would prefer 
to extract selected packets from the detected IP frames instead of generating a response for each 
corresponding (promiscuously) detected IP frame by the emulation application. 

As demonstrated above, both Goddard and Grover explicitly require filtering of packets . 
Hence, assuming one skilled in the art would have been motivated to modify Goddard with the 
teachings of Grover, the hypothetical combination still would neither disclose nor suggest the 
claimed feature of generating, for each corresponding (promiscuously) detected IP frame, a 
response IP frame by an executable emulation application in the protocol emulator, as specified 
in independent claims 1, 12, 19 and 30. 

For these and other reasons, the §103 rejection should be withdrawn. 



In view of the above, it is believed this application is in condition for allowance, and such 
as Notice is respectfully solicited. 

To the extent necessary, Applicant petitions for an extension of time under 37 C.F.R. 
1.136. Please charge any shortage in fees due in connection with the filing of this paper, 
including any missing or insufficient fees under 37 C.F.R. 1.17(a), to Deposit Account No. 
50-1 130, under Order No. 95-451, and please credit any excess fees to such deposit account. 



Conclusion 



Respectfully submitted, 




Leon R. Turkevich 
Registration No. 34,035 



Customer No. 23164 
Date: March 6, 2007 
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